This creates `.emit()` methods on a few primitive things for `keyword`
and `date` style runtime fields. Now you can do stuff like:
```
"d": {
  "type": "date",
  "script": "'2020-01-18T17:41:34.000Z'.emit()"
}
```

We get to piggy back of painless's dynamic dispatch code to regonize
that you are in a `date` and trying to emit a `String` so we can "do the
right thing" without any extra runtime cost. In this case we just parse
the date using the `formatter` on the field. And since the example above
doesn't use a formatter we get ISO8601, the date format of kings.

Similarly, you can do stuff like:
```
"s": {
  "type": "keyword",
  "script": """
    for (int i = 0; i < 100; i++) {
      i.emit();
    }
  """
}
```

Painless *knows* `i` is an `int` and will call an emit method that emits
its string value.

Also! Assuming we get the syntax proposed in elastic#68088, because this is a
chain of method invocations you can do something like:
```
"i": {
  "type": "long",
  "script": """
    grok('%{NUMBER:i} %{NUMBER:j}').extract(doc['message'].value)?.i?.emit()
  """
}
```

This should be read as "if grok matches the message and extracts a value
for `i` then emit it to the runtime field." If either the grok doesn't
match or doesn't extract an `i` value then nothing will be emitted. As
an extra nice thing - we'll automatilly convert whatever the `grok`
expression outputs into a `long`. All of it handled for us using
painless's standard dynamic dispatch code.

…8088)

This adds a `grok` and a `dissect` method to runtime fields which
returns a `Matcher` style object you can use to get the matched
patterns. A fairly simple script to extract the "verb" from an apache
log line with `grok` would look like this:
```
String verb = grok('%{COMMONAPACHELOG}').extract(doc["message"].value)?.verb;
if (verb != null) {
  emit(verb);
}
```

And `dissect` would look like:
```
String verb = dissect('%{clientip} %{ident} %{auth} [%{@timestamp}] "%{verb} %{request} HTTP/%{httpversion}" %{status} %{size}').extract(doc["message"].value)?.verb;
if (verb != null) {
  emit(verb);
}
```

We'll work later to get it down to a clean looking one liner, but for
now, this'll do.

The `grok` and `dissect` methods are special in that they only run at
script compile time. You can't pass non-constants to them. They'll
produce compile errors if you send in a bad pattern. This is nice
because they can be expensive to "compile" and there are many other
optimizations we can make when the patterns are available up front.

Closes elastic#67825

…68332)

This adds a `grok` and a `dissect` method to runtime fields which
returns a `Matcher` style object you can use to get the matched
patterns. A fairly simple script to extract the "verb" from an apache
log line with `grok` would look like this:
```
String verb = grok('%{COMMONAPACHELOG}').extract(doc["message"].value)?.verb;
if (verb != null) {
  emit(verb);
}
```

And `dissect` would look like:
```
String verb = dissect('%{clientip} %{ident} %{auth} [%{@timestamp}] "%{verb} %{request} HTTP/%{httpversion}" %{status} %{size}').extract(doc["message"].value)?.verb;
if (verb != null) {
  emit(verb);
}
```

We'll work later to get it down to a clean looking one liner, but for
now, this'll do.

The `grok` and `dissect` methods are special in that they only run at
script compile time. You can't pass non-constants to them. They'll
produce compile errors if you send in a bad pattern. This is nice
because they can be expensive to "compile" and there are many other
optimizations we can make when the patterns are available up front.

Closes #67825

Replaces the double `Pattern.compile` invocations in painless scripts
with the fancy constant injection we added in elastic#68088. This caused one of
the tests to fail. It turns out that we weren't fully iterating the IR
tree during the constant folding phases. I started experimenting and
added a ton of tests that failed. Then I fixed them by changing the IR
tree walking code.

Replaces the double `Pattern.compile` invocations in painless scripts
with the fancy constant injection we added in #68088. This caused one of
the tests to fail. It turns out that we weren't fully iterating the IR
tree during the constant folding phases. I started experimenting and
added a ton of tests that failed. Then I fixed them by changing the IR
tree walking code.

Replaces the double `Pattern.compile` invocations in painless scripts
with the fancy constant injection we added in elastic#68088. This caused one of
the tests to fail. It turns out that we weren't fully iterating the IR
tree during the constant folding phases. I started experimenting and
added a ton of tests that failed. Then I fixed them by changing the IR
tree walking code.

Replaces the double `Pattern.compile` invocations in painless scripts
with the fancy constant injection we added in #68088. This caused one of
the tests to fail. It turns out that we weren't fully iterating the IR
tree during the constant folding phases. I started experimenting and
added a ton of tests that failed. Then I fixed them by changing the IR
tree walking code.

As of elastic#68088 painless can have methods where all parameters must be
constant. This improves the error message when the parameter isn't. It's
still not super great, but its better and its what we can easilly give
at that point in the compiler.

As of #68088 painless can have methods where all parameters must be
constant. This improves the error message when the parameter isn't. It's
still not super great, but its better and its what we can easilly give
at that point in the compiler.

As of elastic#68088 painless can have methods where all parameters must be
constant. This improves the error message when the parameter isn't. It's
still not super great, but its better and its what we can easilly give
at that point in the compiler.

As of #68088 painless can have methods where all parameters must be
constant. This improves the error message when the parameter isn't. It's
still not super great, but its better and its what we can easilly give
at that point in the compiler.